All committers have signed the CLA.

Thanks for the contribution.
I think it makes more sense to just allow overriding headers for a particular request in all methods. It also looks like that's what initially was proposed in the code snippet in the issue.
@mshustov WDYT?

@slvrtrn that makes sense, but what about the existing auth configuration parameters that get turned into headers? Should custom headers override them, or visa versa?

Also I had a look at the failing integration tests it seems that the CI environment is misconfigured?

I think it makes more sense to just allow overriding headers for a particular request in all methods. It also looks like that's what initially was proposed in the code snippet in the issue.

👍

what about the existing auth configuration parameters that get turned into headers? Should custom headers override them, or visa versa?

I'd vote for allowing users to override any headers (with a debug log record emitted that an override has happened) - it gives more power and flexibility to the end user. For example, one can implement multi-tenant runtime and mange users on the app level

Should custom headers override them, or visa versa?

Let's make the same logic to the default headers in the connection class: https://github.com/ClickHouse/clickhouse-js/blob/main/packages/client-node/src/connection/node_base_connection.ts#L97-L101 (+ buildRequestHeaders)

e.g. can override all except Connection, User-Agent and Authorization. For the authorization header, there is already a separate option in the query settings.

it seems that the CI environment is misconfigured?

Yep, it cannot run the tests with a Cloud instance if a PR is created by an external contributor.